Executable guidance experiences based on implicitly generated guidance models

ABSTRACT

The subject disclosure is directed towards generating an intermediary (e.g., declarative) model based upon reflecting on and interpreting command line applications or the like, to represent a default user interface and default code transformation process. The intermediary model is modifiable to provide a customized output program. The models may be persisted, edited and otherwise modified to perform a management task, for example.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of allowed U.S. application Ser. No.13/802,612 filed on Mar. 13, 2013, titled “Executable GuidanceExperiences Based on Implicitly Generated Guidance Models,” which isincorporated by reference herein in its entirety.

BACKGROUND

Command line applications (such as the Powershell® cmdlets, DOS batchfiles or SQL command) enable a user to execute functionality from atextual command line. To perform meaningful execution, the user needs anunderstanding of the set of input parameters that apply and the validrange of values for each parameter.

For some programming languages, it is possible to reflect on the commandline application and automatically generate a user interface, thusenabling a non-command line user or a novice to execute thefunctionality via the automatically generated user interface, eventhough the original application did not include a user interface. Forexample, Powershell® 3.0 includes “ShowCommand” functionality thatserves this purpose.

However, such existing reflection functionality is designed to be verygeneral, so that the generated user interface widely applies to manyscenarios. As a result, this “one size fits all” form of user interfacegeneration works for simple scenarios, but is inadequate for many otherscenarios.

SUMMARY

This Summary is provided to introduce a selection of representativeconcepts in a simplified form that are further described below in theDetailed Description. This Summary is not intended to identify keyfeatures or essential features of the claimed subject matter, nor is itintended to be used in any way that would limit the scope of the claimedsubject matter.

Briefly, various aspects of the subject matter described herein aredirected towards a technology by which an intermediary model isgenerated from a program that takes as inputs one or more inputparameters and one or more commands. The intermediary model comprises auser interface template corresponding to a default user interface and acode template corresponding to a default transformation program. Theintermediary model may be maintained in memory to allow modification ofthe intermediary model into a modified model that includes modified userinterface data and/or modified code. A modified program corresponding tothe modified model is output.

In one aspect, a model generator program is configured to process aninput program into an intermediary model comprising a user interfacetemplate and a code template comprising declaratives. The modelgenerator program persists the intermediary model to provide for editingthe intermediary model into a modified model that is configured to beinterpreted or compiled into an executable program.

In one aspect, an intermediary model comprising a user interfacetemplate corresponding to a default user interface and a code templatecorresponding to a default transformation program is generated. Amodified model that is based upon the intermediary model is persisted,in which the modified model includes a modified user interface data, atleast one modified parameter, one or more flow conditions and/or one ormore rules that is/are not specified in the intermediary model.

Other advantages may become apparent from the following detaileddescription when taken in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES

The present invention is illustrated by way of example and not limitedin the accompanying figures in which like reference numerals indicatesimilar elements and in which:

FIG. 1 is a block diagram including components configured to generate amodel from an input program, to provide a modified/customized outputprogram, according to one example embodiment.

FIG. 2 is a block diagram representing the modification of anintermediary model into a modified model, according to one exampleembodiment.

FIG. 3 is a flow diagram representing modification of a model, andresulting execution of a corresponding program, according to one exampleembodiment.

FIG. 4 is a block diagram representing an example computing environment,into which aspects of the subject matter described herein may beincorporated.

DETAILED DESCRIPTION

Various aspects of the technology described herein are generallydirected towards reflecting on and interpreting command lineapplications (or commandlets or modules), and then composing anintermediary (e.g., declarative) model used for composing user interfacemodels. In one implementation, an intermediary model is generated torepresent a default user interface and default code transformationprocess. The intermediary model is defined using primarilydeclarative-based mechanisms

Thus, rather than simply generating a user interface, the technologydescribed herein generates an intermediary model that may then bedisplayed using a display user interface layout manager and codetransformation process, for example. Moreover, the intermediary modelmay be persisted and modified by end-users, thus enabling customizedguidance experiences. When the intermediary model is specified in adeclarative manner, non-developers are able to modify the defaultbehavior of the user interface, and people are able to share this work.

It should be understood that any of the examples herein arenon-limiting. As such, the present invention is not limited to anyparticular embodiments, aspects, concepts, structures, functionalitiesor examples described herein. Rather, any of the embodiments, aspects,concepts, structures, functionalities or examples described herein arenon-limiting, and the present invention may be used various ways thatprovide benefits and advantages in computers and management tooling ingeneral.

FIG. 1 shows a block diagram comprising an example implementation in ofa three-stage process for taking an input program 102 (e.g., a Windows®Powershell® cmdlet) and generating a model 104 (implicit model), whichis then used as the basis for rendering a wizard 116, for example. Themodel 104 may be discarded (not persisted), or instead persisted (e.g.,as represented via persistent storage 107) so as to allow a user tomodify the user interface (UI), the validation logic and/or the codetemplate used for generating code. Note that the UI model may be hardcoded, or automatically inferred, e.g., from the cmdlet. Automaticallyinferred models may be edited, e.g., for customization, e.g., asrepresented by the model editor 109 in FIG. 1, which may be a texteditor for text-based models or those able to be converted to text,and/or an editor with additional functionality, such as a graphical userinterface with features that assist with editing the model.

In this example, the user executes a model generator program 108 whichtakes as an input program 102 (e.g., the Windows® Powershell® cmdlet)for which a UI is to be generated. The program 108 may reflect on thesignature of the cmdlet function, the number of parameters, the types ofthese parameters and whether they are optional or mandatory, forexample. This information is then used by the model generator program108 to generate a default UI model 110 (e.g., an Extensible ApplicationMarkup Language (XAML)-based form, such as defining a set of pages intext files and how they interact with each other, e.g., an introductionpage, interaction page and error-handling page) and appropriate inputvalidation logic. The information is also used to generate a defaultcode template 112, e.g., having code in declarative form such asXAML-based.

Note that in extensible scenarios, the model generator program 108presents the generated model to the user to decide on single cmdletversus a pipeline or a workflow. This user input allows for composingcomplex application execution scenarios.

This is exemplified in FIG. 2, where the model generator program 108inputs details regarding the input program 102 from a source 220, (whichmay be learned from the program itself or separately), e.g., what theinput program can take as parameters, what the valid ranges of thoseparameters are, and so forth. Domain expertise 222 further may be usedto determine which of those parameters are applicable to a given task,and, for example, adjust the model generation program 108 to generatethe implicit model 104 with a UI model 210 that applies to the task,possibly limiting the parameters, parameter ranges, setting suitabledefault values, and so forth.

Once the implicit model 104 is generated, it may be persisted orotherwise accessed by an expert 224 or the like (who also may providesome or all of the domain expertise 222). In this way, experts canfurther customize and provide default parameters and flowconditions/rules as desired to the model 104.

The expert 224 may modify the code template 212 and/or UI model 210 forother purposes, e.g., to reuse a UI with a translated language, adifferent company name, and so on. The expert may add flow conditionsand other rules to the code template 212, as generally described belowwith reference to FIG. 3,

The expert 224 (or even a slightly skilled user) also may determinewhether to use the model in a single operation 226, or implement it aspart of a pipeline 228 or other workflow 230. For example, the model 204may be used to present a wizard to a user to obtain user-entered values,with the result of running the program with those wizard-obtained valueschained to another program (e.g., in series or possibly conditionallyselected, (e.g., with the output used to determine a branchingdirection), which in turn may obtain more data and/or performs moreprocessing, and so on, to produce a final output.

Returning to FIG. 1, a model interpreter 114 may take the generatedmodel 104 (comprising the UI model 110 and template 112) and execute themodel 104, providing a wizard 116 (e.g., a single page) or the like toan end-user within which to enter input parameters. Users may extendthis model to include guidance topics, examples and links to knowledgearticles, for example.

After the user completes the wizard 116, a transformation program 118takes the input parameters and inserts them into the code template 112via transformation. This results in a modified (e.g., customized)program 120 (e.g., a Windows® Powershell® script or a pipeline ofWindows® Powershell® scripts that are executable by the Windows®Powershell® interpreter). Each script can be shown to the user prior toexecution or executed transparently. The artifacts generated by theseprocesses such as UI Wizards, associated models and context may becollectively referred to herein as guidance packages.

In general and as described above, a given model generator program(e.g., 108) is typically configured with domain expertise 222 thatenables the model generator program 108 to know what to look for in itsinput objects (e.g., parameters and types of parameters for PowerShell®,HTML domain object model, or DOM, for forms and so on), such that themodel generator program 108 can then generate an appropriate model.

By way of example, consider a model generator that is designed for webforms, e.g., an HTML form that is used to provide credit cardinformation for an e-commerce site. The model generator is programmed toincorporate domain expertise, such that it is able to recognize inputcontrols that are relevant to this process and then build a model. Thatmodel (conceivably) may be used on other ecommerce sites, except that inmany cases the forms will have different naming conventions. Thus, auser may modify the model such that the model alters its behavior ondifferent sites. The model interpreter thus may be provided with theability to customize behavior depending on who the host is.

As another example, consider a deployment process in which someonedeploying a product has to type a large number of commands into acommand line interface in order to have the deployment solution install.Each of these commands has different points of variability, and some ofthese will be significant for someone else that also may want to performthat same set of actions (e.g., steps).

In such an instance, a model generator may be configured to “record” theactions being performed, and use the recorded information to generate amodel that makes it possible for an advanced user to then go andremove/customize/add to those steps based on an understanding of what ispossible at each of the steps. It is feasible to have a model generatorthat is taught how to look for this expertise in a general class ofproblems, e.g., a model generator that works across multiple commandline environments and is able to infer characteristics about theseenvironments, which it may then use to support implementation in aspecific class of command line environments.

Turning to another aspect, users may want to customize the behavior ofthe UI, e.g., to enable a standardized guidance experience within anorganization or across a type of user. As described herein, this may bedone via editing or similar interaction to provide a customized programfor a command line application. Moreover, customization may be furtherextended to enable more complex execution scenarios, such as where theuser may need to execute a workflow having of a sequence of command lineapplications. This is based upon chaining of command line applications,where the inputs may be collected in each step of execution based on theconditions involved.

Moreover, the user interface model does not need to be sequential as inthe example of a wizard. Instead, the implicit model may includeinternal branching logic, (as well as be coupled for input from and/oroutput to other models). For example, for a debit card, the userinterface may branch to another page or the like to obtain the user'sdebit card PIN, whereas for a credit card, the user interface may branchto another page to obtain some form of credit card signature orvalidation data such as expiration date/security code. The userinterface model also may be configured to automatically gather data fromother sources, e.g., for automated balance checking, credit checkapproval, and/or the like.

FIG. 3 is a simplified example in which a model generator programoutputs a model 330, with simplified code template “commands” shown forreadability (instead of the actual page rendering code, input code andvalidation code, for example). At any time, an expert may modify thecode template, such as to add branching conditions, as represented viablock 332.

When the code in block 332 is run as Transformation program1, asrepresented via block 333, the code will present page A to the user toreceive input for the specified parameter associated with page A, namelyParameter7. Note that via the model, input parameters need not belimited to standard command line input such as single values, but mayinclude complex parameters such as name/value pair (maps to literal/textfield) displays, e.g., arrays, collections of variably typedinformation, XML structures and so forth.

Based upon the user input, at step 340 of Transformation program1 334,the value entered determines the next page to output, e.g., Page B forParameter7=X, Page C for Parameter7=Y, or no further page for Parameter7equal to something other than X or Y, e.g., default values are used foroutput.

If Page B is output at step 342, this page collects a value for aparameter Q. If instead page C is output at step 344, this page collectsa value for a different parameter R.

In the example of FIG. 3, the Transformation program1 334 is chained to(outputs its results to) Transformation program2 346, which consumes theoutput as its input. Thus, in this simplified example, Transformationprogram2 346 executes with the value for parameter Q plus default valuesfor any other parameters, or with the value for parameter R plus defaultvalues for any other parameters, or with all default values. As can beseen, an initial model may be modified to include other code, includingbranching logic and the like, and the modified model may be coupled to(e.g., chained to) one or more other models. Note that instead of aserial chain or pipeline, a model may selectively branch between othermodels in a workflow or the like based upon its output, e.g., viaintervening logic, which may itself be a model. Thus, an expert maybuild one or more execution paths within a model, and couple that modelto other existing or modified models, in a straightforward manner.

As can be seen, the technology (e.g., tooling) described herein removesthe typical constraints (e.g., hard coded wizards with no insight intoexecution logic) that typically accompanies management tools. Branchinglogic, different user interfaces, and the like allow differentcombinations of parameters to be used to execute differentfunctionality. Also, input parameters may have complex interdependenciesnot easily inferred through conventional command-line reflection.

In addition, the technology helps in compiling complex applications withgreater confidence, as well as removing cumbersome/complex issues. Forexample, users of command line applications normally get guidance helpfrom explicit invocation of the desired command with proper helpparameters (-help option or ‘?’). This is cumbersome for complex commandline applications where the user needs guidance, samplescripts/snippets, and/or knowledge articles along the way, including forexample, an option to execute the application in a sandbox and see theresults. This technology helps to inject proper guidance to the commandexecution pipeline and thus helps the end user to execute code, withconfidence.

Example Operating Environment

FIG. 4 illustrates an example of a suitable computing and networkingenvironment 400 into which the examples and implementations of any ofFIGS. 1-3 may be implemented, for example. The computing systemenvironment 400 is only one example of a suitable computing environmentand is not intended to suggest any limitation as to the scope of use orfunctionality of the invention. Neither should the computing environment400 be interpreted as having any dependency or requirement relating toany one or combination of components illustrated in the exampleoperating environment 400.

The invention is operational with numerous other general purpose orspecial purpose computing system environments or configurations.Examples of well-known computing systems, environments, and/orconfigurations that may be suitable for use with the invention include,but are not limited to: personal computers, server computers, hand-heldor laptop devices, tablet devices, multiprocessor systems,microprocessor-based systems, set top boxes, programmable consumerelectronics, network PCs, minicomputers, mainframe computers,distributed computing environments that include any of the above systemsor devices, and the like.

The invention may be described in the general context ofcomputer-executable instructions, such as program modules, beingexecuted by a computer. Generally, program modules include routines,programs, objects, components, data structures, and so forth, whichperform particular tasks or implement particular abstract data types.The invention may also be practiced in distributed computingenvironments where tasks are performed by remote processing devices thatare linked through a communications network. In a distributed computingenvironment, program modules may be located in local and/or remotecomputer storage media including memory storage devices.

With reference to FIG. 4, an example system for implementing variousaspects of the invention may include a general purpose computing devicein the form of a computer 410. Components of the computer 410 mayinclude, but are not limited to, a processing unit 420, a system memory430, and a system bus 421 that couples various system componentsincluding the system memory to the processing unit 420. The system bus421 may be any of several types of bus structures including a memory busor memory controller, a peripheral bus, and a local bus using any of avariety of bus architectures. By way of example, and not limitation,such architectures include Industry Standard Architecture (ISA) bus,Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, VideoElectronics Standards Association (VESA) local bus, and PeripheralComponent Interconnect (PCI) bus also known as Mezzanine bus.

The computer 410 typically includes a variety of computer-readablemedia. Computer-readable media can be any available media that can beaccessed by the computer 410 and includes both volatile and nonvolatilemedia, and removable and non-removable media. By way of example, and notlimitation, computer-readable media may comprise computer storage mediaand communication media. Computer storage media includes volatile andnonvolatile, removable and non-removable media implemented in any methodor technology for storage of information such as computer-readableinstructions, data structures, program modules or other data. Computerstorage media includes, but is not limited to, RAM, ROM, EEPROM, flashmemory or other memory technology, CD-ROM, digital versatile disks (DVD)or other optical disk storage, magnetic cassettes, magnetic tape,magnetic disk storage or other magnetic storage devices, or any othermedium which can be used to store the desired information and which canaccessed by the computer 410. Communication media typically embodiescomputer-readable instructions, data structures, program modules orother data in a modulated data signal such as a carrier wave or othertransport mechanism and includes any information delivery media. Theterm “modulated data signal” means a signal that has one or more of itscharacteristics set or changed in such a manner as to encode informationin the signal. By way of example, and not limitation, communicationmedia includes wired media such as a wired network or direct-wiredconnection, and wireless media such as acoustic, RF, infrared and otherwireless media. Combinations of the any of the above may also beincluded within the scope of computer-readable media.

The system memory 430 includes computer storage media in the form ofvolatile and/or nonvolatile memory such as read only memory (ROM) 431and random access memory (RAM) 432. A basic input/output system 433(BIOS), containing the basic routines that help to transfer informationbetween elements within computer 410, such as during start-up, istypically stored in ROM 431. RAM 432 typically contains data and/orprogram modules that are immediately accessible to and/or presentlybeing operated on by processing unit 420. By way of example, and notlimitation, FIG. 4 illustrates operating system 434, applicationprograms 435, other program modules 436 and program data 437.

The computer 410 may also include other removable/non-removable,volatile/nonvolatile computer storage media. By way of example only,FIG. 4 illustrates a hard disk drive 441 that reads from or writes tonon-removable, nonvolatile magnetic media, a magnetic disk drive 451that reads from or writes to a removable, nonvolatile magnetic disk 452,and an optical disk drive 455 that reads from or writes to a removable,nonvolatile optical disk 456 such as a CD ROM or other optical media.Other removable/non-removable, volatile/nonvolatile computer storagemedia that can be used in the example operating environment include, butare not limited to, magnetic tape cassettes, flash memory cards, digitalversatile disks, digital video tape, solid state RAM, solid state ROM,and the like. The hard disk drive 441 is typically connected to thesystem bus 421 through a non-removable memory interface such asinterface 440, and magnetic disk drive 451 and optical disk drive 455are typically connected to the system bus 421 by a removable memoryinterface, such as interface 450.

The drives and their associated computer storage media, described aboveand illustrated in FIG. 4, provide storage of computer-readableinstructions, data structures, program modules and other data for thecomputer 410. In FIG. 4, for example, hard disk drive 441 is illustratedas storing operating system 444, application programs 445, other programmodules 446 and program data 447. Note that these components can eitherbe the same as or different from operating system 434, applicationprograms 435, other program modules 436, and program data 437. Operatingsystem 444, application programs 445, other program modules 446, andprogram data 447 are given different numbers herein to illustrate that,at a minimum, they are different copies. A user may enter commands andinformation into the computer 410 through input devices such as atablet, or electronic digitizer, 464, a microphone 463, a keyboard 462and pointing device 461, commonly referred to as mouse, trackball ortouch pad. Other input devices not shown in FIG. 4 may include ajoystick, game pad, satellite dish, scanner, or the like. These andother input devices are often connected to the processing unit 420through a user input interface 460 that is coupled to the system bus,but may be connected by other interface and bus structures, such as aparallel port, game port or a universal serial bus (USB). A monitor 491or other type of display device is also connected to the system bus 421via an interface, such as a video interface 490. The monitor 491 mayalso be integrated with a touch-screen panel or the like. Note that themonitor and/or touch screen panel can be physically coupled to a housingin which the computing device 410 is incorporated, such as in atablet-type personal computer. In addition, computers such as thecomputing device 410 may also include other peripheral output devicessuch as speakers 495 and printer 496, which may be connected through anoutput peripheral interface 494 or the like.

The computer 410 may operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computer480. The remote computer 480 may be a personal computer, a server, arouter, a network PC, a peer device or other common network node, andtypically includes many or all of the elements described above relativeto the computer 410, although only a memory storage device 481 has beenillustrated in FIG. 4. The logical connections depicted in FIG. 4include one or more local area networks (LAN) 471 and one or more widearea networks (WAN) 473, but may also include other networks. Suchnetworking environments are commonplace in offices, enterprise-widecomputer networks, intranets and the Internet.

When used in a LAN networking environment, the computer 410 is connectedto the LAN 471 through a network interface or adapter 470. When used ina WAN networking environment, the computer 410 typically includes amodem 472 or other means for establishing communications over the WAN473, such as the Internet. The modem 472, which may be internal orexternal, may be connected to the system bus 421 via the user inputinterface 460 or other appropriate mechanism. A wireless networkingcomponent 474 such as comprising an interface and antenna may be coupledthrough a suitable device such as an access point or peer computer to aWAN or LAN. In a networked environment, program modules depictedrelative to the computer 410, or portions thereof, may be stored in theremote memory storage device. By way of example, and not limitation,FIG. 4 illustrates remote application programs 485 as residing on memorydevice 481. It may be appreciated that the network connections shown areexamples and other means of establishing a communications link betweenthe computers may be used.

An auxiliary subsystem 499 (e.g., for auxiliary display of content) maybe connected via the user interface 460 to allow data such as programcontent, system status and event notifications to be provided to theuser, even if the main portions of the computer system are in a lowpower state. The auxiliary subsystem 499 may be connected to the modem472 and/or network interface 470 to allow communication between thesesystems while the main processing unit 420 is in a low power state.

Example Embodiments

In an embodiment, a method comprises, generating an intermediary modelfrom a program that takes as inputs one or more input parameters and oneor more commands, the intermediary model comprising a user interfacetemplate corresponding to a default user interface and a code templatecorresponding to a default transformation program, maintaining theintermediary model in memory to allow modification into a modified modelthat includes modified user interface data or modified code, or bothmodified user interface data and modified code, and outputting amodified program corresponding to the modified model.

In an embodiment, the outputting the modified program corresponding tothe modified model comprises interpreting the model into user interfacedata that is rendered, and transforming the model based upon inputreceived via the user interface data.

In an embodiment, the method further comprises coupling the modifiedprogram to at least one other program.

In an embodiment, the coupling the modified program comprises includingthe modified program in a pipeline of programs, in which at least oneprogram's output is consumed as input by at least one other program.

In an embodiment, the coupling the modified program comprises includingthe modified program in a workflow of programs, in which at least oneprogram's output determines a branching direction between a plurality ofother programs.

In an embodiment, the method further comprises, executing the modifiedprogram corresponding to the modified model, in which the modifiedprogram includes branching logic that was added during a modification ofthe intermediary model into the modified model.

In an embodiment, the maintaining the intermediary model in memorycomprises persisting the intermediary model in non-volatile storage.

In an embodiment, the generating the intermediary model includesrecording actions being performed, and using at least one of therecorded actions to generate the intermediary model.

In another embodiment, a system comprises, a model generator programconfigured to process an input program into an intermediary modelcomprising a user interface template and a code template comprisingdeclaratives, the model generator program further configured to persistthe intermediary model to provide for editing the intermediary modelinto a modified model, the modified model configured to be interpretedor compiled into an executable program.

In an embodiment, the model generator program is configured to beconstructed with domain-specific data.

In an embodiment, the executable program is configured to receive inputfrom one program or to provide output to another program, or to bothreceive input from one program and provide output to another program.

In an embodiment, the executable program is implemented as a componentin a serial pipeline of components.

In an embodiment, the executable program is implemented as a componentin a conditional workflow containing components.

In an embodiment, the modified model contains at least one conditionalbranch.

In an embodiment, the input program comprises a command lineapplication.

In an embodiment, the model generator program reflects on a commandletassociated with the input program.

In an embodiment, the model generator program reflects on a moduleassociated with the input program.

In an embodiment, the executable program inputs complex parameters.

In another embodiment, one or more computer-readable media havingcomputer-executable instructions, which when executed perform steps,comprises, generating an intermediary model comprising a user interfacetemplate corresponding to a default user interface and a code template,and persisting a modified model that is based upon the intermediarymodel, in which the modified model includes at least one of: userinterface data, one or more modified parameters, one or more flowconditions or one or more rules that is not specified in theintermediary model.

In an embodiment, further computer-executable instructions comprise,executing executable code corresponding to the modified model.

CONCLUSION

While the invention is susceptible to various modifications andalternative constructions, certain illustrated embodiments thereof areshown in the drawings and have been described above in detail. It shouldbe understood, however, that there is no intention to limit theinvention to the specific forms disclosed, but on the contrary, theintention is to cover all modifications, alternative constructions, andequivalents falling within the spirit and scope of the invention.

What is claimed is:
 1. A method comprising: receiving an input program;extracting information relating to program parameters from the inputprogram, the information including at least one of a number, a type, ornecessity of the program parameters; generating an implicit model thatcomprises a user interface model and a code template based on theextracted information; generating, from the implicit model, a userinterface configured to accept one or more input parameters from a user;and inserting the one or more input parameters into the code template togenerate a customized program.
 2. The method of claim 1, wherein theuser interface model comprises input validation logic.
 3. The method ofclaim 1, further comprising: extending the user interface model toenable an implementation of at least one of a pipeline or workflow ofoperations.
 4. The method of claim 1, further comprising: enabling thecode template to be modified to provide at least one of defaultparameters, flow conditions, or rules.
 5. The method of claim 1, furthercomprising: extending the implicit model to include at least one ofguidance topics, examples, or links to knowledge articles.
 6. The methodof claim 1, further comprising: modifying the implicit model to includebranching logic to generate a modified implicit model, the branchinglogic being configured to branch to a first page for obtaining a firstset of user input and to branch to a second page for a second set ofuser input.
 7. The method of claim 6, further comprising: chaining themodified implicit model to one or more other models.
 8. A systemimplemented in at least one computing device, comprising: a modelgenerator configured to receive an input program, extract informationrelating to program parameters from the input program, the informationincluding at least one of a number, a type, or necessity of the programparameters, generate an implicit model that comprises a user interfacemodel and a code template based on the extracted information, a modelinterpreter configured to generate, from the implicit model, a userinterface configured to accept one or more input parameters from a user;and a transformation program configured to insert the one or more inputparameters into the code template to generate a customized program. 9.The system of claim 8, wherein the user interface model comprises inputvalidation logic.
 10. The system of claim 8, wherein the model generatoris further configured to extend the user interface model to enable animplementation of at least one of a pipeline or workflow of operations.11. The system of claim 8, wherein the model generator is furtherconfigured to enable the code template to be modified to provide atleast one of default parameters, flow conditions, and rules.
 12. Thesystem of claim 8, wherein the model generator is further configured toenable the implicit model to be modified to include branching logic togenerate a modified implicit model, the branching logic being configuredto branch to a first page for obtaining a first set of user input and tobranch to a second page for a second set of user input.
 13. The systemof claim 12, wherein the model generator is further configured to chainthe modified implicit model to one or more other models.
 14. A computerprogram product comprising a memory storage device having computerprogram logic recorded thereon that when executed by a computer causesthe computer to perform a method, the method comprising: receiving aninput program; extracting information relating to program parametersfrom the input program, the information including at least one of anumber, a type, or necessity of the program parameters; generating animplicit model that comprises a user interface model and a code templatebased on the extracted information; generating, from the implicit model,a user interface configured to accept one or more input parameters froma user; and inserting the one or more input parameters into the codetemplate to generate a customized program.
 15. The computer programproduct of claim 14, wherein the user interface model comprises inputvalidation logic.
 16. The computer program product of claim 14, whereinthe method further comprises: extending the user interface model toenable an implementation of at least one of a pipeline or workflow ofoperations.
 17. The computer program product of claim 14, wherein themethod further comprises: enabling the code template to be modified toprovide at least one of default parameters, flow conditions, and rules.18. The computer program product of claim 14, wherein the method furthercomprises: extending the implicit model to include at least one ofguidance topics, examples, and links to knowledge articles.
 19. Thecomputer program product of claim 14, wherein the method furthercomprises: modifying the implicit model to include branching logic togenerate a modified implicit model, the branching logic being configuredto branch to a first page for obtaining a first set of user input and tobranch to a second page for a second set of user input.
 20. The computerprogram product of claim 19, wherein the method further comprises:chaining the modified implicit model to one or more other models.